低延遲主機的設定被改掉，或重開機後沒有套用時，服務不會中斷，也不會觸發告警，只有收發延遲變慢。例如網卡中斷跟回覆程式原本在同一顆 CPU，被分到不同 CPU 之後，收發延遲中位數從 3.89 µs 變成 4.64 µs；kernel bypass 沒生效時，程式改走 kernel 的網路堆疊，中位數從 1.21 µs 變成 4.16 µs。這類問題只能定期跟基線比對才抓得到，這篇把要檢查的設定跟運作指標寫成巡檢腳本，整理成三件事：

1. 巡檢兩類項目：一類是被改掉時延遲會變長的設定，另一類是運作指標，像是封包壞掉、被丟掉或佇列擁塞時會增加的計數器，以及防火牆的 CPU 使用率。
2. 執行頻率分三種：計數器跟防火牆 CPU 交給監控系統每分鐘取樣，每天開盤前把全部項目檢查一次，每次變更前後各存一份 snapshot。
3. 每個項目輸出一行結果，有問題的標 FAIL 或 WARN，再分兩級：P1 在交易時段由值班立即處理，P2 在下次開盤前處理完。

檢查哪些

下表最後一欄是項目異常時的影響，量過的附上實測數字：

多久跑一次、交給誰

腳本的做法

腳本只用 Python 標準函式庫，正式環境的伺服器不用另外安裝套件；登入設備是呼叫系統的 ssh 指令，用 SSH 金鑰認證，設定檔不存放密碼。設備清單是一個設定檔，每台設備寫類型、管理位址、登入帳號跟要檢查的項目：

[sw-lowlat]
type = arista
host = 198.51.100.10
user = inspect
items = forwarding_mode errors discards link_changes lanz igmp config

每次執行分四步：

1. 登入每台設備執行檢查指令，把每個項目的原始輸出存成 snapshot，留作稽核紀錄，後面的比對也用它。
2. 設定項目逐行跟核准過的 snapshot（基線）比，列出改過的行；計數器跟上一次的 snapshot 相減，算出這段期間增加多少。
3. 每個項目印一行結果：檢查沒過標 FAIL，要注意但還不算失敗的標 WARN（例如防火牆 CPU 超過 70%），LANZ 沒到上限的紀錄標 INFO，只記錄不通報。FAIL 依項目列為 P1 或 P2，交易時段以外的 P1 降為 P2；WARN 一律列為 P2。
4. 結果另存成 JSON 給監控系統讀，腳本結束時也會回傳代碼（exit code）：0 是沒有異常、1 是有 WARN、2 是有 FAIL，呼叫腳本的排程或監控系統依代碼決定要不要通知值班。

這些判斷用測試資料驗過，資料多半取自實驗時存下來的交換器、防火牆輸出。同一份資料比兩次，沒有 FAIL 或 WARN；故意改壞 10 個地方，例如轉發模式改成 store-and-forward、出口 discards 增加，每一處都標出預期的 FAIL 或 WARN，以及 P1 或 P2，連不上的設備也會標 FAIL。同樣的異常如果發生在交易時段以外，P1 都會降為 P2。

變更驗證的流程

1. 變更前存一份 snapshot，量一輪收發延遲當基準。
2. 變更做完再存一份 snapshot，跟變更前那份比，只有預期要改的項目不同才算通過。
3. 再量一輪收發延遲跟基準比，中位數高 5%、p99 高 10%，或出現超過中位數 10 倍的請求（每輪最前面兩個請求本來就慢，不算在內），任何一項成立就不通過。
4. p99.9 跟抖動（PDV）重量一輪本來就會跳動，所以 p99.9 高 10%、PDV 到基準的 1.5 倍時，先重量一輪，仍超過才不通過。
5. 通過的話，審核的人把變更後那份 snapshot 核准為新的基線；不通過就把變更改回去（rollback），再存一份 snapshot，確認所有項目都跟變更前那份一樣。

明天把 FortiGate 防火牆串接進量測路徑，比較硬體加速開啟與關閉時，封包經過防火牆的延遲。